[SM90] Sparse decode: honor topk_length for DeepSeek-V3.2 - #27

Summary

The SM90 sparse decode kernel honors topk_length only for the DeepSeek-V4 layout; for V3.2 it asserts topk_length == nullptr. SM100 already honors it for V3.2. This makes SM90 consistent:

• The per-request block count comes from topk_length, rounded up to 64 with at least one block, which matches what get_decoding_sched_meta plans.
• Index positions at or past topk_length are treated as invalid, as in the V4 path.
• The checks are compiled in only for two new instantiations, v32_persistent_h{64,128}_topklen.cu, selected when topk_length is given (the same scheme as the SM90 sparse prefill kernel). The existing V3.2 kernels are unchanged.

The same kernel change is proposed upstream in deepseek-ai#216 (open, not reviewed yet), also as a compile-time specialization. This PR is for the fork, whose source layout differs, because vLLM needs it for DCP (vllm-project/vllm#58980). If deepseek-ai#216 lands upstream first, a later sync can replace this.

Motivation

vLLM runs V3.2 with decode context parallelism, where each rank owns about 1/dcp of every 2048-wide top-k row. Today the kernel runs on the full row with the other ranks' slots masked as -1. Compacting the rank's slots and passing their count as topk_length (one batch entry per token) skips the masked slots.

Kernel time on one DCP4 rank (H20, h_q=64, top-k 2048, ~512 owned slots per row):

The lengths differ per layer, so vLLM plans every call; the last column includes that planner run. A companion PR, opened at the same time, makes the planner 2.1-3.6x faster at these batch sizes.

End to end in vLLM (8x H20, TP8 + DCP4, vllm-project/vllm#58980), the prefill time of fresh prompts drops by 24-28%, and the decode step time by 3.9-8.3% at 16-32 concurrent requests. At 8 requests the per-layer planning cancels the gain out until the planner is faster.

Tests

• tests/test_flash_mla_sparse_decoding.py now also generates V3.2 cases with topk_length: 180 new correctness cases. The harness poisons every KV row not selected within topk_length with NaN, so any read past the length fails.
• All 4896 SM90 correctness cases pass on H20 (420 V3.2, 4476 V4, 2232 with topk_length).
• No change for callers that don't pass topk_length. FlashMLA's SM90 decode perf cases before/after, best of two runs (us):

V4 cases are within ±0.9% as well.

Not tested on SM100; this PR doesn't touch SM100 code.

AI assistance (Claude) was used for this change. I reviewed all of it and ran the tests above.